home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6148 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.0 KB  |  115 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: comp.vuw.ac.nz!HERMES!maths!peterm
  3. From: peterm@maths.grace.cri.nz (Peter McGavin)
  4. Subject: Re: Scrolling only selected bitplanes
  5. Message-ID: <PETERM.96Mar25143904@tui.maths.irl.cri.nz>
  6. Date: 25 Mar 1996 02:39:04 GMT
  7. Distribution: world
  8. References: <314e1835@beachyhd.demon.co.uk> <2628.6653T1T2571@mbox.vol.it>
  9. Organization: Industrial Research Ltd
  10. In-reply-to: bizzetti@mbox.vol.it's message of 19 Mar 1996 23:07:28 GMT
  11.  
  12. bizzetti@mbox.vol.it (Fabio Bizzetti) writes:
  13. >>I am currently drawing (using WritePixel()) and scrolling (using
  14. >>ScrollRaster()). However, I want to be able to draw and scroll completely
  15. >>*independently* of the final bitplane. So I draw and scroll planes 1 through
  16. >>7, but plane 8 stays completely undisturbed.
  17. >
  18. >Sorry to say it, but this is a good example of reality about OS and direct
  19. >hardware programming.
  20.  
  21. The OS provides SetWrMask() that should solve this problem.  It should
  22. even work with gfx cards.
  23.  
  24. >And also if there's a way to do it with the OS, it'll be damn slower
  25. >and expecially damn more innatural and complex than it has to be.
  26.  
  27. ...and more compatible/portable.  Maybe slower, but I would argue more
  28. natural and less complex.  Compare: e.g, OpenScreen() with setting up
  29. all the display and palette registers and copperlists for a simple
  30. 256-colour display.
  31.  
  32. Personally I have nothing against games that access hardware directly,
  33. provided:
  34.  
  35.   o  it's really necessary for performance or functionality;
  36.  
  37.   o  the game checks for the correct hardware first and doesn't
  38.        crash without warning on different hardware;
  39.  
  40.   o  the game exclusively allocates the hardware thru the OS before
  41.        trying to access it;
  42.  
  43.   o  the game provides options for different hardware and/or high
  44.        level OS calls where feasible;
  45.  
  46.   o  ideally the hardware access should be isolated in low levels
  47.        of the game, e.g, custom device drivers;
  48.  
  49.   o  the game obeys all OS rules
  50.  
  51. The correct hardware can be checked for in places like
  52. ExecBase->AttnFlags, GfxBase->ChipRevBits0 and the displayinfo
  53. database.
  54.  
  55. Most Amiga hardware can be exclusively allocated thru the OS.  For
  56. example, the blitter can be allocated with OwnBlitter() or QBlit().
  57. There are routines for allocating sprites.  Other custom graphics
  58. hardware can be allocated with LoadView(NULL); WaitTOF(); WaitTOF().
  59. Then the game can bang away at the copper to its heart's content.
  60. Restore the original View at the end.  Depending on the game, however,
  61. it might be better to use a plain Intuition Screen and access the
  62. bitmap directly (after checking that it is a native, planar bitmap)
  63. and/or maybe open an Intuition Screen with a user copper list.
  64.  
  65. An input-handler can eliminate 95% of OS overheads (they come from
  66. Intuition and console.device) and give the illusion of single-tasking
  67. without disabling multitasking.  The game can continue async hard-disk
  68. caching of texture data, network play, OS calls, maybe even its own
  69. multiple tasks, etc.  At the same time, an input-handler provides
  70. low-level, portable, efficient keyboard and mouse input that is
  71. expected to work on all and future Amigas.
  72.  
  73. Other hardware resources, such as timers, serial and parallel ports,
  74. audio channels, etc, can be allocated if required (but better to use
  75. high-level OS calls for compatibility if possible).
  76.  
  77. About the only Amiga hardware that cannot be directly accessed within
  78. OS rules (without rebooting afterwards) are the 680x0 interrupt
  79. vectors.  Interrupts must be installed with AddIntServer(),
  80. SetIntVector(), QBlit(), AddICRVector(), etc.  Interrupts may not be
  81. disabled for more than 250 microseconds.  It's not really a problem
  82. once an input-handler is installed because OS interrupt overheads are
  83. so small.
  84.  
  85. Failure to obey these rules can result in lockups, crashes, frozen
  86. networks and corrupted hard disks on Amigas with third-party
  87. peripherals such as network cards, disk controllers, etc.  Also, the
  88. game will most likely fail with 680x0 emulation on PPC Amigas.
  89.  
  90. From my own personal experience, it seems that about half the games
  91. and demos that install their own interrupt vectors ignore the VBR.
  92. About half of the rest fail on fast Amigas because they clear the
  93. interrupt too close before the RTE.  On fast Amigas, that doesn't
  94. allow for propagation time through the slow custom chips and so the
  95. interrupt occurs again unexpectedly.  Of course the OS interrupt
  96. handling routines know about these things.
  97.  
  98. Similar problems seem to occur with most keyboard banging routines.
  99. They either don't wait long enough for certain keyboards (such as the
  100. A3000 one that needs a longer delay) or they wait so long for all
  101. keyboards that the extra delay totally eliminates the speed advantage
  102. of killing the OS.
  103.  
  104. Well, either that or they spend 10 times as long waiting for the
  105. vertical blank or waiting for a mouse click or using slow algorithms
  106. as the speed gain they made by killing the entire OS.
  107.  
  108. >What are the king of games?: consoles. Have you ever seen a console
  109. >programmed through an OS such as Amiga's one?
  110.  
  111. I didn't buy my Amiga just for games.
  112. -- 
  113. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  114.  
  115.